If a user Alice wishes to access her patient portal at her medical provider, she typically has to obtain unique credentials (e.g. UserID/Password) for the patient portal. However, Alice typically would also have credentials from other sites, such as those for her on-line banking site or those from her employer. The notion that can Alice can leverage the credential issued by one entity to access another entity is the concept of an identity federation. The technology and standards for achieving identity federations have existed in various forms for many decades. Standards such as SAML and OpenID have similarly been in existence for a long time. In terms of adoption such cross-organization identity federation has not seen widespread adoption. Rather the technology (sometimes called single sign-on or SSO) is used more widely within a given organization to allow users to use a single credential to access multiple services. There are several reasons why cross organizational identity federations have been slow to be adopted. First, there is the “n squared connections” problem wherein for n organizations to cooperate in a federation about squared connections will have to be maintained. Further, while there is standardization happening, there still exist multiple standards, and even the implementation of a given standard can have variability.
Identity Exchanges have started appearing as a potential solution to some of these problems. As shown in FIG. 1 an Identity Exchange (110) acts as a “switchboard” between the various entities (121, 122, 123, . . . 131, 132, 133, . . . ) in the federation. The entities provided identity assertions are referred to as Identity Providers (IdP) and the entities consuming identity assertions are referred to as Relying Parties (RP). In a typical flow the user (100) visits the RP (say 131) site, is prompted to select the IdP (say 121) they wish to use to log in and is redirected to the IdP via the Identity Exchange (110) with a identity assertion request. The IdP authenticates the user, creates a response consisting of an identity assertion and the user is directed back to the RP via the Identity Exchange. In this model each IdP and RP has to maintain a single connection to the Identity Exchange solving the “n squared” problem. Further, the Identity Exchange can perform protocol translations and allow for interoperability
There is a further problem which identity federations can help solve, namely, in our description above when Alice selects the IdP she wants to use, the RP learns the name of that IdP. Further, when the IdP provides the response it learns which RP Alice is visiting. To bring it back to our original example, if Alice user her on-line banking credential to log in to her patient portal at her health clinic, then the health clinic learns where she banks, and the bank knows which health clinic she is visiting. In some cases this can result in an unacceptable loss of privacy. To solve this issue the notion of double blinded Identity Exchanges were introduced and are currently used in some countries for government run Identity Exchanges. Here the Identity Exchange acts as a middleman which shields the true identity of the IdP from the RP and that of the RP from the IdP.
The central problem with Identity Exchanges is that the exchange itself becomes a single point through which all traffic flows and a security failure at the exchange itself will be catastrophic. For a comprehensive description of the importance of this problem the interested reader is referred to “Privacy Enhanced Identity Brokers”, published on Oct. 19, 2015 by the National Cyber Security Center of Excellence a part of the National Institute of Standards and Technology (NIST). See https://nccoe.nist.gov/sites/default/files/library/project-descriptions/privacy-enhanced-identity-brokers-project-description-draft.pdf.